1. Field of the Invention
The present invention relates to computer interfaces, in particular to tactile-based user interfaces suited for use by visually impaired computer users, and more particularly for use by visually impaired engineers and engineering students in connection with engineering design software.
2. Brief Description of the Related Art
The ability to use the techniques, skills, and modern engineering tools necessary for engineering practice is an important requirement for engineering student education and graduation. Germane to this outcome is the use of simulation software, for such software represents a key engineering tool that students must master to practice engineering in the modern world. For example, chemical engineers use process simulation software to solve material and energy balances for proposed manufacturing schemes, or to analyze current processes for the application of possible improvements (i.e., “de-bottlenecking”). Examples of software used by chemical engineers for this purpose include PRO/II by Simulation Sciences, Inc.; ASPEN by ASPEN Technology, Inc.; and CHEMCAD by Chemstations, Inc. Each of these software packages function in a generally similar fashion, and familiarity with one confers a transferable knowledge base to operate another, provided that the basic input/output (I/O) routines are understood. Choices of components and flow rates, thermodynamic methods, unit operations, and unit connectivity are provided by the user as input, and the calculation engine then performs the material and energy balance, sizes or rates equipment, and in some cases provides an estimate of the capital investment associated with a design or improvement.
Recent advances in simulation software design have moved from text-based (i.e., keyword and programming language code) input to Graphical User Interfaces (GUIs). GUIs are exceptionally attractive to professors because they allow for a significant time savings during student training. Simply put, classroom exercises are freed of debugging the keyword syntax required to run the calculation engine. Since pointing and clicking generates the code, presumably more time is spent understanding the chemical process being studied and how it may be correctly designed or improved. For example, the simulation of a facility to produce ethylene oxide described in the popular design textbook Analysis, Synthesis, and Design of Chemical Processes may be built with a GUI by dragging twenty-three appropriate unit operation icons to a design palette, indicating connectivity with lines between icons, filling in appropriate drop-down menus, and then pushing the run button. This generates approximately 200 lines of keyword code by PRO/II, for example, which is then processed through the calculation engine. Entry of this code by hand would take considerably longer than implementing this design using the GUI provided by the software.
One may consider, however, the difficulty associated with using a GUI if a person has limited or no vision. Classroom activities must obviously accommodate this student in order for the student to succeed. Two avenues exist for student accommodation: (i) falling back, so to speak, to the exclusive use of keyword files, or (ii) adapting the I/O routine of the software package. The inventors of the present invention believe that completely circumventing the use of a GUI may not be a viable long-term option for a visually impaired student. The overall requirement of providing instruction for all design students makes the use of GUIs invaluable. It is the inventors' understanding, however, that in order for a federally funded university to be in compliance with section 504 of the Vocational Rehabilitations Act of 1973 (Public Law 93-112), accommodations must be made for all qualified students. Although the visually impaired student could work solely with text-based code, the quality of modern instruction would be sorely compromised for several reasons. First, the time allotted to creative exercises would be diminished to allow for the writing and debugging of keyword files. Second, avoiding GUIs conflicts with the appropriate training outcome. Third, the creation of a separate and distinct educational track for the visually impaired student only delays the inevitable difficulties that will faced by the visually impaired engineering student when that student faces real-world engineering tasks as a practicing engineer. Since the visually impaired student would function in a group setting with sighted team members, a disparity would exist simply because sighted engineers and visually impaired engineers would approach process simulation differently. Those able to employ a GUI would arguably try more possible solutions, whereas those constrained to keyword code may examine fewer scenarios, perhaps resulting in a sub-optimal solution to a particular engineering problem. Such scenarios are clearly not acceptable in modern chemical engineering education and practice.
The art includes a number of attempts to make various types of computer software packages usable by those persons with impaired vision. In particular, there are several methods used by educators of the visually impaired to convey scientific or mathematical content using software. These techniques typically require some visual acuity to produce material for the student. The “one-way” techniques include complicated and costly methods, such as Pictures In A Flash (PIAF), provided by Quantum Technology of Sydney, Australia, and more simple methods, such as raised-line drawing kits, which are provided through numerous sources including Maxi-Aids, Inc. of Farmingdale, N.Y. PIAF, or “toasting” as it is routinely called, is a technique that transfers material from a master to swell paper using heat. First, an image is produced from material, be it handmade or graphic printout. The image is then transferred using a simple copy machine onto the swell paper, then raised by exposing the copy to a concentrated light source. PIAF is more costly because of the paper and light box, but can quickly prepare material for a student. At the opposite end of the cost spectrum is the raised-line drawing kit. Using this technique, an image is transferred to a thin acetate film by pressure. A stylus similar to those packaged with personal digital assistants (PDAs) is used to score the film, producing a line. PIAF and similar methods are considered “one way” in as much as a person with visual acuity is required and because they are not interactive; static representations of material (like graphs or diagrams) are produced for a student to interpret, but there is no means by which the student may manipulate those materials directly.
Screen-reading software is a second technique for allowing the visually impaired to interact with computer software. Although digital access has evolved and developed over the years, the basic idea of using screen-reading software dates back to the days of early personal computing, and has remained generally the same since that time. Screen readers have long existed (examples include TextTalker for the Apple II, and VocalEyes for personal computers running the Microsoft DOS operating system) that were able to vocalize the screen content as new information was printed to it in a line-by-line fashion. Since an application only had text strings and numerical values as input or output, manipulating information was relatively easy. Though graphics did exist and limited GUIs were available, the main media by which information was conveyed was text based, due to the limited computer power that was then available.
With faster processors, more memory, and cheaper storage media, GUIs became more profitable to build, maintain, and run on desktop computers. Pointing and clicking is the current standard by which I/O is achieved. Microsoft introduced the Windows operating system, generating selection pressure towards the creation of “attractive” software relying on GUIs. Since visually impaired users were required to manipulate GUIs, utility programs were created that could coherently read graphical information on the screen. Starting in 1997, Microsoft's Active Accessibility (MSAA) team built and continues to build special tools, APIs (Application Programming Interfaces), and accessibility standards into the Windows operating system that allow leading screen reading packages (such as Jaws for Windows from Freedom Scientific, Inc., and WindowEyes from GwMicro, Inc.) to provide computing accessibility to visually impaired professionals. Unfortunately, the architecture of many GUI-based technical programs does not employ MSAA features. This creates a dilemma for visually impaired users. When one launches an application using non-standard controls (i.e., graphics, or unlabelled objects and buttons) that the screen reader cannot recognize or interpret via MSAA or through the Windows API, the blind person is plunged back into illiteracy. Such is the case, for example, with standard plant simulation software used by chemical engineers, such as CHEMCAD, ASPEN, or PRO/II. Although screen readers can interpret some aspects of the interface, many times there are crucial parts of the GUI that cannot be manipulated with screen-reading programs. One critical aspect of these interfaces includes connecting unit operations via point, click, and/or drag. These operations are essential for effective use of such software.
Another attempt to make software usable by those persons with visual impairment is by the use of imbedded audio cues. Non-visual cues, including audible cues may be imbedded in the software to mimic events normally indicated by visual cues, such as textual elements like a cursor shape change. Non-visual cues may include audible cues, such as spoken words or sounds, vibrations, kinetic, or any other cue that may be sensed. This strategy requires a willingness on the part of the software developer to adapt the software package. For users with only limited vision, the accurate location of screen items is difficult or in some cases impossible. To overcome these difficulties, distinct sounds may be introduced. For example, consider when a user is trying to indicate a stream connection from Unit A to Unit B. Conceptually, the user moves the cursor around the icon of Unit A and encounters an available port. When the port is found, a sound can be played to indicate successful capture of the port at either Unit A or Unit B. Sounds may also be used to indicate other functions as well. With the feedback of sounds, users with limited vision may be promptly informed of events that screen reading programs cannot indicate. The problem with this approach is that it requires the publisher of the software to imbed the audio cues in the software itself, making the adaptation of the software for the visually impaired difficult if this effort was not made when the software was written.
Finally, tactile representations may be used to locate and place GUI objects. Tactile representations may be as simple as a small sticker placed on a transparency or as complex as a stenciled analog of the icon being represented. A stencil may be designed to mimic the same size of the onscreen icon and provide the user with the needed level of detail to indicate connectivity. Without tactile representations, the inventors believe it is almost impossible to design a facility using the drop and click features of a GUI. Tactile representations alone, however, are believed to be insufficient to provide a complete representation of software functionality to facilitate effective use by a person who is visually impaired.
References mentioned in this background section are not admitted to be prior art with respect to the present invention. The limitations of the prior art are overcome by the present invention as described below.